1. Field of the Invention
The present invention relates generally to a wireless communication system, and more particularly, to a resource request procedure in a wireless communication system.
2. Description of the Related Art
Several generations of communication networks, such as radio communication systems, have been developed to this point. Such radio communication systems include the First Generation system (1G), Second Generation system (2G), Third Generation system (3G) and Fourth Generation system (4G). Each generation has different transmission characteristics and communication technologies.
The 1G systems, such as Advanced Mobile Phone System (AMPS), and Total Access Communications System (TACS), is based on analog frequency modulation technology. The 2G system, such as Global System for Mobile communications (GSM), is based on Time Division Multiple Access (TDMA). The 3G systems, such as Universal Mobile Telecommunications System (UMTS) and GSM Evolution (EDGE), are based on a Wideband Code Division Multiple Access (WCDMA) air interface. The 4G system is an International Telecommunication Union (ITU) specification that is presently being developed for broadband mobile capabilities. The 4G system would enable Internet Protocol (IP) packet-based voice data and streaming multimedia at higher speeds than with the 3G system. Transmission resources in the 4G wireless communication systems are shared among many users, such as mobile phones or User Equipments (UEs). Therefore, the data availability for transmission is reported by the UE to network element, such as an evolved (e) NodeB, to receive transmission resources (corresponding grants) from the network for the actual transmission of the data. The report is called a Buffer Status Report (BSR).
However, for calculating BSR, the data that arrives from higher layers in a protocol stack are accounted for transmission. As such, no consideration is given in the BSR for packets generated at other layers. Further, a Packet Data Convergence Protocol (PDCP) status report that is capable of preventing the occurrence of data loss is also not considered for BSR. The PDCP status report conveys to the peer entity the reception status of the PDCP Protocol Data Units (PDU) following a handover.
The application or upper layer data packet termed as Service Data Units (SDU) is processed at the PDCP layer, and the resultant data packet formed is termed a PDU. The PDCP status report carries information indicating whether reception of the PDUs is successful. For example, the PDCP report includes information about the PDU(s) that have been received successfully and the PDU(s) that were not received or were missing, thus needing retransmission. Hence, the size of the PDCP status report is variable.
Thus, during handover, a peer entity (network) performs transmissions and retransmissions on the basis of the PDCP status report to achieve a lossless handover. Therefore, the PDCP status report should also be considered for BSR. Currently, the PDCP report is not considered for computing data availability for transmission, and as such, the reported BSR conveyed to the network is not accurate enough.
A network element computes on the basis of the received BSR and provides grants to the UE. The grants provided would not match the actual transmission requirements at the UE. There may be a case in which some data may incur a delay in transmission until sufficient grants are subsequently received. When there is no application or upper layer data existing, the existing method would send a BSR conveying zero value. However, there may be PDCP status report available which needs to be transmitted.
Therefore, when no user data is available, the BSR report makes no requirements and thus, no grant is fetched. Hence, a PDCP status report cannot be transmitted. The PDCP Status Report is mandated as the first UpLink (UL) packet (in some access technologies) after the handover; therefore, absence of a grant to send the status report will result in a deadlock situation.
This deadlock cannot be broken until some new user data or application data arrives. However, any delay in transmission of a PDCP status report in UL would cause the DownLink (DL) to also suffer, and the network would not perform timely transmissions and retransmissions. When the network element discovers a zero requirement BSR, it may discard the packets which otherwise would need to be re-transmitted to the UE based on its PDCP Status Report, thus incurring packet losses on the bearer.
Also, to achieve a desired Quality of Service (QoS), the network element limits the maximum delay in transmitting the upper layer. Thus, application data is subject to an expiration of the discard timer, and the corresponding user data is discarded. During handover scenarios, it is likely that the upper layer data, which was available before handover, gets discarded after handover completion based on the discard timer(s) expiration. The timing values for discard timers and handover procedure completion are comparable.
Although the header compression feedback related control information is generated at the PDCP layer, there would be a mismatch in actual transmission resource requirement and the reported BSR (and thereby the allocated grant), as the header compression feedback related control information is not accounted for BSR, resulting in transmission delay of some data. Another adverse effect is that the data packets would undergo an undesired segmentation/re-segmentation for requesting of a sufficient grant, thereby leading to increased processing complexity and inefficiency at the UE.
Hence, there exists a need for a method to efficiently manage resource requirements in the mobile communication network.